Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

refactor(frontend): remove fallback from ic-token derived stores #2358

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

refactor(frontend): remove fallback from ic-token derived stores #2358

wants to merge 4 commits into from

Conversation

AntonioVentilii-DFINITY
Copy link
Contributor

@AntonioVentilii-DFINITY AntonioVentilii-DFINITY commented Sep 15, 2024 •
edited
Loading

Motivation

The derived store tokenWithFallback falls back on ETH (or SepoliaETH) and consequently even the store tokenWithFallbackAsIcToken.

However, it is unnecessary for the derived stores that checks if a particular token is a ck-token, since ETH will never have a prop ledgerCanisterId (and the util functions checks for a non-nullish token).

So we remove that particular usage from the code substituting tokenWithFallbackAsIcToken with tokenAsIcToken.

@AntonioVentilii-DFINITY AntonioVentilii-DFINITY marked this pull request as ready for review September 15, 2024 21:32
peterpeterparker
peterpeterparker reviewed Sep 16, 2024
View reviewed changes
Copy link
Member

@peterpeterparker peterpeterparker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure it works in every use case and feature of the dApp? Have you thoroughly tested this? tokenAsIcToken is actually cast as IcToken, but after reviewing the code, it seems to be a shorthand, as it can actually be null or undefined.

On another note, could you first provide a test in a separate PR for the existing derived stores modified in this PR? It would be great to start testing those stores, given that this information is highly sensitive. WDYT?

@AntonioVentilii-DFINITY
Copy link
Contributor Author

On another note, could you first provide a test in a separate PR for the existing derived stores modified in this PR?

You mean the utils inside the stores? Or the whole logic of the derived stores?

@peterpeterparker
Copy link
Member

Or the whole logic of the derived stores?

I meant the all logic - like starting testing derived stores

@AntonioVentilii-DFINITY AntonioVentilii-DFINITY marked this pull request as draft September 18, 2024 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@peterpeterparker peterpeterparker peterpeterparker left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@AntonioVentilii-DFINITY @peterpeterparker